
Remarks 

In the Office Action mailed November 6, 2003: 

1 . Claims 1,11 and 20 were objected to because of inforaialities; 

2. Claims 1, 4, 6, 8, 9, 1 1-12 and 14-20 were rejected under 35 U.S.C. § 102(b) as 
being anticipated by U.S. Patent No. 5,737,531 (Ehley); 

3. Claims 2, 3 and 10 were rejected under 35 U.S.C. § 103(a) in view of Ehley; 

4. Claims 5, 7 and 13 were objected to, but would be allowable if rewritten in 
independent form including all of the limitations of the base claim and any 
intervening claims. 

I. Informalities 

Claims 1,11 and 20 have been amended to correct the noted errors. 

II. Ehley (U.S. Patent 5,737,531) 

Ehley is directed to the synchronization of media streams through the use of feedback 
from a target to a source of the streams (column 5, lines 54-59). Resynchronization in Ehley 
differs significantly from the method and apparatus of Applicants' present invention. 

A. In Ehley, Loss of Synchronization is Detected at a Client 

Ehley's method of resynchronization depends on feedback provided by a client . This is 
evident in passages cited by the Examiner relating to Figure 7 (e.g., column 11, lines 13-23; 
column 11, lines 30-33; column 11, lines 54-59). Figure 7 "illustrates the client software and 
hardware architecture" (column 6, lines 35-36). 

In contrast, the present invention relates to operations performed at a server . For 
example, "a media streaming server may determine that a streamed media program is out of 
synchronization" (page 2, lines 25-26; emphasis added). 

As just one consequence of this difference between Ehley and the present application, in 
Ehley, a large number of clients may overwhelm a server with identical or substantially identical 
feedback if they are all out of synchronization. In the present invention, the server would notice 
the loss of synchronization without having to ingest such a large amount of feedback. 
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B. Ehley's Method of Resynchronization Differs Significantly from Applicants' 

An examination of the Ehley resynchronization method reveals that it is quite different 
from AppUcants' claimed methods. In particular, Ehley discusses resynchronization between a 
master stream and a slave stream on a client (column 5, line 66 to column 6, line 3). Ehley 
describes two methods of accomplishing the resynchronization, depending on whether the slave 
track is behind or ahead of the master track. 

If the slave track is behind the master track, the client sends a message to the server 
telling it to drop a number of frames (column 1 1, line 66 to column 12, line 1 ; element 802 of 
Figure 8; column 13, lines 33-49). This obviously does not involve "selecting a second time 
index later in said media," as recited in Applicants' claim 1. 

If the slave stream is ahead of the master track, a wake-up time for the slave stream is 
increased to slow the slave stream (column 1 1, lines 49-54). This causes the next frame in the 
slave stream to be processed at a slightly later time than it would be processed otherwise. This, 
however, is very different from Applicants' method of attempting to resynchronize at a later 
media time index. 

To illustrate the difference, assume that Ehley's system plays a particular frame (e.g., 
frame A). Following a loss of synchronization, where the client detects that the slave stream is 
ahead of the master stream, Ehley simply plays frame A+1 at a slightly later time than it would 
have otherwise. The media time index has not changed and no "second media time index" was 
selected for resynchronization. In Applicants' present invention, when the server detects a loss 
of synchronization after frame A, it selects a second, later, media time index (e.g., A+B) and 
attempts to resynchronize at that media time index. 

HI. Selected Claims 

A. Claims 1-7 and 16 

Claims 1 and 16 have been amended to make it clearer that the claimed method is 
performed at a server, rather than a client. As described above in section II. A, Ehley does not 
teach or suggest the detection of a loss of synchronization at a server. 
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1. Dropping frames is not equivalent to selecting a second media time index 
The Examiner cited several portions of Ehley (column 12, lines 59-61; column 13, lines 

39-59; element 802A of Figure 8; claim 1) as evidence of Ehley's anticipation of the "selecting a 
second media time index" element of claims 1 and 16. However, dropping a number of frames 
in a stream that is chronically behind a master stream is not the same as selecting a media time 
index. The "media time index" refers to the position in the overall media stream that should be 
played. Dropping frames from the slave stream does nothing to alter the media time index; it 
merely attempts to get the slave stream back to the current media time index. 

In addition, and as described in section 11. A, in Ehley it is the client that determines the 
number of frames to drop. Therefore, even if dropping frames was equivalent to selecting a later 
media time index, it is not the server that performs this action. 

2, Ehley does not attempt to resvnchronize at a later media time index 
Because dropping frames is not equivalent to selecting a later media time index at which 

to resynchronize, Ehley does not teach or suggest such an attempt to resynchronize. Ehley 
merely tries to get a slower slave track to speed up and resynchronize at the current media time 
index. 

B, Claims 8-15 and 17 

Claims 8 and 17 have been amended to make it clearer that the claimed method is 
performed at a server, rather than a client. As described above in section II.A, Ehley does not 
teach or suggest the detection of a loss of synchronization at a server. 

Applicants traverse the rejection of claims 8 and 17 for the same reasons as stated above 
in section III.A, and for other reasons. 

1. Ehley does not hah the streaming of a media program 
Ehley's dropping of frames (column 11, line 66 to colunm 12, line 3) does not halt 
streaming. Instead, by dropping a number of frames from a slave stream when it is "chronically 
behind" the master stream, the system attempts to catch the slave stream up to the master stream. 
Therefore, it would not stop . Instead, it keeps streaming frames - the frames immediately 
following the ones that are dropped. 
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C. Claim 18 

Claim 1 8 has been amended to make it clearer that the apparatus is a server, not a client, 
in the embodiment of the invention recited in this claim. As described above in section 11. A, 
Ehley does not teach or suggest the detection of a loss of synchronization at a server. 

D. Claims 19-20 

Claims 19-20 have been amended to claim a media server, and not a client. As described 
above in section II.A, Ehley does not teach or suggest the detection of a loss of synchronization 
at a server. 



No new matter has been added with the preceding amendments. It is submitted that the 
application is in suitable condition for allowance. Such action is respectfully requested. If 
prosecution of this application may be facilitated through a telephone interview, the Examiner is 
invited to contact Applicant's attorney identified below. 



Park, Vaughan & Fleming LLP 

702 Marshall Street, Suite 310 
Redwood City, CA 94063 
(650) 474-1973: voice 
(650) 474- 1976: facsimile 
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Respectfully submitted. 



Date: January 9, 2004 




